ソフトウェア見積り 人月の暗黙知を解き明かす
https://m.media-amazon.com/images/I/41ISjzPazVL._SX260_.jpg
はじめに
本書ではサイエンスとしての見積りではなくアートとしての見積りを扱う
サイエンスとしての見積り : 複雑な公式などを用いて、誤差 ± 5 % 以内にも収まるような結果を出す
アートとしての見積り : 単純な公式と経験則。 実践的なソフトウェアのプロフェッショナルにとって効果的
本書の対象者 : 多くの職務のひとつとしてたまに見積りをするような開発者、責任者、テスト担当者やマネジャー
巨大プロジェクトの見積りは対象外 (それらはプロの見積り作成者が行うべきもの)
1 部 : 見積りの考え方
1 章 : 見積りとは
見積りと計画は密接な関係にあるが、見積りは計画を立てることではないし、計画は見積りを作ることではない 見積りは、先入観のない分析的なプロセス (ゴールは正確性)
計画は、先入観を排除せずにゴールを指向するプロセス (ゴールは特定の結果の追及)
見積りを求められたら、実際に見積もりを行うのか、ターゲットの達成方法を訊かれているのかを判断すること シングルポイントの見積りは、見積りとして意味がない
それは本当に見積りなのか、ターゲットを表しているのか見極める必要がある
見積りだとすれば、その確率を確認する必要がある
ソフトウェア見積りの主目的は、プロジェクトのターゲットが現実的なのか、達成可能なのかを判断すること
見積りにとって重要なことは、完璧なまでに正確であることより、有用な情報を提供すること
見積りに近い結果の実現には、正確な見積り、適切なターゲットの設定、適正な計画とコントロールの三拍子がそろう必要
よい見積りとは :
良い見積りとは、プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで、適正な意思決定ができる明確な視点を提供する見積りである。 2 章 : 見積り能力のチェック
「90 % の確度」 と言われても、多くの人がそれに準ずる見積りはできない
→ 定量的に導き出した根拠をもたない限り、「パーセント確度」 の見積りを設定してはいけない
見積りの幅を狭くしすぎる人が多い → 不必要に見積り幅を狭めてはいけない。 あるべき確度との整合を確認すること
明確なプレッシャーがないのに見積り幅を狭くするプレッシャーを感じる人も多い (実際には自分の思い込み) → 見積り幅を狭くするプレッシャーを感じる場合、それが自分の思い込みでないことを確かめること
3 章 : 正確な見積りの価値
過大見積りと過小見積りのどっちがましか？ → 過大見積りの方がまし
過大見積りをしてしまうと……
過小見積りをしてしまうと……
特定のアクティビティに誤った前提が入ってしまい、効果的な計画を作れない
予定通りに完了する可能性が低くなる
開発者が作る見積りは、一般的に実際の工数よりも 20 ～ 30 % 小さい
最初に時間がかけられないことで後にもっと大きなコストがかかってしまう
遅延することによりさらに無駄な作業が生じる (どうやって取り戻すか検討する、とか)
ソフトウェア業界では、過小見積りが多い → 我々はまずは見積りを多くすることからはじめるべし
正確な見積りの利点
状況の可視化が進む (予実管理しやすくなる)
品質向上 : スケジュールのストレスによる品質問題の回避
ソフトウェアのエラーの 40 % はストレスによって引き起こされる
ソフトウェア以外の業務部門との連携がよくなる : 良い見積りは、ソフトウェア以外のアクティビティも含む
などなど
経営陣は、予測可能性を重視することが多い (予測可能性が常に重要、という意味ではなく、優先度について思い込みをしてはならない、という話) 「スケジュールを 1 ヵ月早められる可能性が高いが遅れる可能性も少しある (ばらつきが大きい)」 という状況よりも、「完了見込みの時期がばらつかない」 という状況を好む
ステークホルダーへのコミットメントは予測可能性によって担保されるため
4 章 : 見積り誤差はなぜ起きる？
5 章 見積りに影響するもの
ソフトウェアの規模が大きいほど工数は増える (最も重要)
規模を見積もらずにコストや工数、スケジュールを見積もってしまう場合がある
LOC での規模の見積りに意味があるのか疑問であれば 18 章を参照 規模が大きくなるほど、あるいはコミュニケーションパスが増えるほど、単位あたりの工数が増える → 規模の不経済 開発するソフトウェアの種類 (次に重要)
人的要因 (3 番目に重要)
プログラミング言語の選択も影響
その言語やツールの利用経験があるかどうかが生産性に 40 % の影響を与える
言語に付随するツール類が最悪な環境だと、最高の場合と比べて総工数が 50 % 程度増加
インタープリタ言語の方がコンパイラ言語で作業するより 2 倍速い
nobuoka.icon 20 年以上前の研究なので、現在では違ってる気がする
その他の要因
各因子の重みづけはプロジェクトの規模によって変える必要がある
プロジェクトの計画とコントロールの観点から
小中規模のプロジェクトは個人の力量で成功の大部分が決まる
大規模プロジェクトでは、個人の力量も大事だが、プロジェクトマネジメントの度合い (特にリスクについて) や組織の成熟度、個人がチームに溶け込む度合いなどが重要になる
2 部 : 見積り技法の基礎
6 章 見積り技法入門
見積り技法はどんな見積り対象にも適用できるものが多いが、工数の見積りに適したものや所要期間の見積りに適したもの、納品できる機能数の見積りに適したものなどがある
本書での定義
規模の見積り : 所定の機能の技術的なスコープを見積る (コード行数やファンクションポイント、ストーリーなどが単位) 機能の見積り : スケジュールと予算の制約内で納品できる機能の数 プロジェクト規模に応じた見積り技法
小規模 : ボトムアップ技法 (実際に作業する個々のメンバーによる見積り)
大規模 (半年から 1 年以上継続する 25 人以上のチーム) : 初期はアルゴリズムと統計によるトップダウン、中期にはトップダウンとプロジェクト自身の過去データを用いたボトムアップ、後期にはボトムアップ技法
最終的にはボトムアップに移行する
反復型開発の方が、プロジェクト固有のデータを用いた詳細な見積りに移行しやすい 7 章 数えて、計算して、判断する
まず数えられるなら数えよう
それができないなら、根拠ある数字を数えて、それを基に計算する
計算した値を専門家の判断で変更しない (それは正確性を下げる)
判断に頼るのはどうしようもないときだけ
ここが見積りの品質を落とす箇所
何を数えるか？
初期に数えられるもの : マーケティング要求、機能、ユースケース、ストーリーなど
中期には、より多くなる
過去データを収集していると、数えたものから見積りを出しやすい
欠陥あたりの平均工数や web ページ当たりの平均工数、ストーリーやユースケース当たりの平均工数など
8 章 補正と過去のデータ
数えたものを見積りに変換するために補正する
12 章 代替指標による見積り
16 章 うまくいく見積りのフロー
17 章 標準化された見積り手順
3 部 : 見積りの課題
18 章 規模の見積りの課題
19 章 工数の見積りの課題
20 章 スケジュールの見積りの課題